In the early days of desktop publishing, most publications contained only text and simple black and white line drawings that were output to black and white laser printers. However, due to advances in computer hardware and software, business professionals and graphic artists now regularly create and produce complex, full color publications. This near commercial quality work may include black and white, grayscale, and color images, acquired from imaging devices such as desktop and handheld scanners, or digital still and video cameras.
In order to include such images in a document, it is necessary for a software application being used to create the document to acquire image information from an imaging device. Under many conventional schemes, a user must first leave the application program used to create the document, locate and open a hardware driver for the imaging device, set various device options, acquire the image, make any desired modifications to the image, save the image to disk, close the hardware driver, return to the document application, and then locate and insert the image file from disk into the document. This process is both time consuming and tedious. Most business professionals, designers, or publishers would prefer a simpler approach that perhaps offers fewer control options, but is more efficient when all that is needed is to simply acquire an image with an imaging device and insert the image into a document.
In order to overcome some of the limitations associated with these conventional schemes, hardware and software developers began defining their own image acquisition interfaces that were specific to each application in which an image might be acquired. However, writing a separate driver for each imaging device that is desired to be supported by an application is clearly not an optimal solution. Similarly, it doesn't make sense to ask a hardware vendor to write a different driver to interface its imaging device with each different software application. More importantly, users should not have to deal with many unique application/device drivers in order to get their application programs to communicate with imaging devices.
In 1991, a small group of hardware and software developers, lead by such companies as Hewlett Packard Corporation and Canon Corporation, proposed to simplify the image acquisition process through the development of a standard imaging device communication specification. The resulting specification has lead to the development of the TWAIN API and protocol, which enable application program developers to include support for various image acquisition devices without requiring special drivers for each different device and/or application. The TWAIN API and protocol (hereinafter often referred to simply as “TWAIN”) is currently the industry standard for implementing the use of image acquisition devices in application programs.
While TWAIN provides substantial benefits, it still has its limitations. For instance, applications that implement TWAIN generally use many built-in features, such as TWAIN's device selection dialog, or built-in dialogs for setting image capture parameters that are written by various vendors who manufacturer imaging devices that support the standard. Oftentimes, a user may desire to simply insert an image using default settings that will be appropriate for most image acquisitions, rather than having to select various settings through the use of dialogs. Thus, it would be desirable to provide means within any application program that will enable a user to capture and insert an image with minimal user input and/or knowledge of imaging device parameters. The TWAIN API is also quite complex, making it difficult for programmers with limited or no TWAIN experience to implement. Thus, it would also be desirable to enable an application program developer to be able to include support for image acquisition devices without requiring the developer to directly write procedure calls to the TWAIN API.